This is only a rough draft - Megan 04/16/92 The following meeting agenda was presented on the Chassis MIB working group mailing list before the meeting. ----------------------------------------------------------- Chassis MIB WG -- March 17, 1992 Bob Stewart rlstewart@eng.xyplex.com Jeff Case case@cs.utk.edu Mailing List: chassismib@cs.utk.edu chassismib-request@cs.utk.edu to add/delete/modify Welcome Introductions Review Charter Chassis Information Model Define Scope of Work Review Contributed MIBs Keith McCloghrie, Hughes LAN Systems (kzm@hls.com) and Donna McMaster, Synoptics (mcmaster@synoptics.com) Manu Kaycee, Cabletron (kaycee@ctron.com) Plan For Producing Baseline Documents Next Meeting Date and Location ----------------------------------------------------------- We discussed the charter, concentrating on the three work areas: mapping logical functions to physical devices, power supplies, and aggregation. This discussion was limited to the meaning of the charter with technical discussion deferred to later in the meeting. The major points regarding the charter for logical to physical mapping (the Chassis MIB, proper) were: . This is a "meta-MIB", pointing to other MIBs. . Multiple instances of the same device may have "virtual agents." . Any system in any slot may implement the Chassis MIB. . One agent may point all slots to the same agent. The major points regarding the charter for a power supply MIB were: . "Power supply" may include environment, such as fans and temperature. . "Power supply" most likely does not include items such as interrupt vectors and memory jumpers. . Environment perhaps should be a separate MIB. . Discussion should stay focussed on a "network" chassis, not general VME, Multibus, PC bus or such. Little was said at this point regarding aggregation. Regarding the general constraints, the major points were: . This is NOT the place for a VME MIB. . Large companies, such as IBM, are not considered as standards bodies. . For the sake of robustness, reliance on third parties is to be avoided. The charter was accepted as written. The group discussed the scope of work for a Power Supply MIB. The major points were: . Many are interested having such a MIB, few are interested in working on it. . A document is not useful if it does not result in widespread implementations. . A poll of what current implementations provide obtained: state, backup, voltage, current, etcetera ad nauseum. . A Power Supply MIB might point to an Environment MIB. . A Power Supply MIB is applicable outside a chassis, but a power supply in a chassis is more important than in a single system. . What is available across implementations resulted in a consensus for on/off status and an average of 4/5 variables from about 25 companies. . Who is actually using this information resulted in responses from Hughes, Digital, Synoptics, Chipcom, Fibronics, NCR, and several others. . Everyone who has such variables is to send relevant MIB segments to Bob Stewart for compilation, including temperature, fans, and such. The group discussed the scope of work for aggregate information. The major points were: . Widespread confusion over what this topic means concluded that this is to be an assessment of "how is it (a group of entities) working". . The answer to "Why with the Chassis MIB?" was because a chassis creates a well-identified group. . The group agreed the definition is still to vague, what constitutes a group? . Is there anything like this now? There is some CMIP work which will be one of our proposals, along with two others. . Examples of aggregation are total errors, total packets, and such. . Jeff wants to do this. . Some specific examples are traffic in and out of a regional network, or the sum of ifInOctets for a group. . Might this solve the problem of SNMP management for non- SNMP devices not necessarily in a chassis? No. . This is an interesting next step in network management, but may be beyond the reasonable scope of this working group. . Synoptics has a MIB for the health of a device, set by rules. . The RMON MIB totals things, but is LAN-bound. . This looks like artificial intelligence. . In favor of this work, but shouldn't be called "chassis." . Does the rule of not defining objects deducible from others preclude this? No, that was a rule for initial definition of MIB I. . Conclusion was that this is useful, important work, many want to work on it and want the product of that work. The working group concluded that the Chassis MIB is of primary importance, a Power Supply MIB is worth working on if there is enough common ground, and an Aggregation MIB may combine in some ways with the Chassis MIB or may need to be separated so as not to adversely effect delivery of a Chassis MIB, which is the primary deliverable. The working group then turned to presentations of possible Chassis MIBs. Keith McCloghrie presented a proposed Chassis MIB that he and Donna McMaster prepared for the Multiport Repeater Working Group. [The McChassis MIB?] The major points presented were: . Purpose is to manage a box with multiple modules. The box comprises physical modules (slots), logical devices (repeaters, bridges, etc.), backplane "wires" (Ethernet, Token Ring, FDDI, etc.), and power supply. . Physical devices are indexed by slot number. They have an object identifier for board type (including empty and unknown), and a time of last insertion or removal. . Logical devices are integer indexed. They have a function (a sum of values such as repeater, bridge, or terminal server), the device's sysObjectId, and, for SNMP access, an SNMP party object identifier or a community string and IP address. Issues here included relationship to SMUX and UPD ports, non-IP addressing, and multiple communities for get and set. . Backplane wires are integer indexed and have an object identifier to indicate type. . A configuration table has an entry for each relation with a slot number, a logical device index, and a backplane wire index, meaning that (part of) the logical device is in the slot and connected to the indicated backplane wire. Several such entries may make up a single logical device. . Concepts in the document but not on the original slides include a status object and a null index to indicate lack of relevance, such as no backplane wire for a power supply. . Additional issues include definition of "chassis", generalization of "slot" to include "physical device," more information such as ifIndex or ifOperStatus, inclusion of external "wires," what is a proper device (such as a host), a directory of devices beyond a chassis, and the number of tables (done to be concise). Manu Kaycee presented a Chassis MIB being implemented as a private extension by Cabletron. The major points presented were: . Requirements are to support hub-based products, many-to- many associations, logical and physical representations, physical partitioning of components and tables, MIB discovery, multiple component instances, virtual chassis. . MIB is very similar to Keith and Donna's. . Lacks map from logical device to backplane wires. . Adds chassis type for agent-supporting device. . Backplane includes VME or such. . Has a slot count. . Component table includes adminStatus (needs operStatus), string to pass with initialize command, name, software version, access policy. . Slot table indexed by slot and component to give map. It includes slot class for restricted slots, a unique module ID, and is empty if "chassis" is slotless. . Includes a (controversial) MIB group table, indexed by slot, component, and group that can distribute the MIB-II ifTable across slots and could be VERY big. . This is currently being implemented, Cabletron will share experience if that is helpful. Jeff called for additional proposals. Two were offered to be submitted by mid April. First draft MIB to appear as soon as possible after final call for proposals on mailing list. The working group decided not to have an interim meeting, especially not at Interop. Discussion will be via email. Respectfully submitted, Bob Stewart